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What  is  an  API? 


•  Provides  a  service  that  receives  and  operates  on  some  type  of 
data,  and  returns  data  or  some  type  of  status  regarding  the 
success  or  fai  I  u re  of  the  servi ce  attempted . 

►  Developed  in  a  non-proprietary  and  open  system  format. 

►  Provides  flexibility  where  ever  possible. 

►  Layered  and  focused  on  interfaces. 

•  Provides  traceability  from  API  to  defined  system  requirements. 

•  Designed  for  reuse  and  interoperability  (define  physical/logical  interfaces). 

-  Defined  to  isolate  dependencies,  to  ease  porting. 

-  Defined  to  be  adaptable  in  order  to  map  to  a  variety  of  implementations. 

•  Defined  such  that  they  can  be  replaced  by  emerging  standards  as  they  mature  and 
are  accepted  by  industry  and  DoD. 

•  Designed  for  testability  (carry  through  conformance/validation  requirements). 

►  Include  industry,  academia,  and  standards  bodies  to  the  degree  possible  when 
defining  new  API’s. 
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API  Based  Software  Reference 
_ Architecture _ 

•  Concentrates  on  interface  definition  by  identifying  applicable  APIs 
and  standards  for  physical  and  logical  interfaces. 

►  Utilizes  SAE  GOA  model  as  a  clear  concise  framework  to  partition  capability. 

►  Concentrates  on  interfaces  to  achieve  interoperability,  not  products. 

•  Benefits  of  using  an  API  based  Architecture: 

►  Promotes  reuse  at  multiple  layers. 

►  Minimizes  application  impact  from  insertion  of  new  technologies. 

►  Facilitates  interoperability  through  the  identification  of  unambiguous  interface 
definitions. 

►  Enables  plug  and  play  capability  not  only  at  the  resource  access  services  layer 
(hw/drivers),  but  at  the  system  services  and  application  layers  as  well. 
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Example  Software  Architecture  based  on 
the  Vetronics  Reference  Architecture 
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Operating  Environment  (OE)  API 


•  OE  is  the  mechanism  to  facilitate  application  porting  among 
platforms. 

•  Supports  the  development  of  portable,  reusable  applications. 

►  Support  the  development  of  embedded  applications  in  heterogeneous 
distributed  real  time  environments. 

►  Provide  semantic/behavioral  correctness  across  varying  OS  and  hardware 
platforms  with  predictable  performance. 

►  Provide  extensibility  and  scalability  to  suit  varying  platform  requirements. 

►  Support  distributed  applications  integration  environments. 

•  Communication  and  synchronization  mechanisms  developed  to  support  the 

relocation  of  OE  applications  among  processors  and  LRUs  within  a  system  without 
requiring  the  modification  of  application  software. 

►  Support  the  development  and  interoperability  of  applications  in  multiple 
programming  languages  (Ada  83,  Ada  95,  C)  utilizing  distinct  OE  vendor 
implementations . 
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Evolution  of  the  OE  Concept 


A 


Product:  Standard  Software  Module  (SSM) 

Contract:  Standard  ArmyVetronics  Architecture  (SAVA) 
ContractoKFMC,  GDLS,  Tl,  General  Electric 
Time:  1988-1"9Q2  \ 


Product:  Combat  Vehicle  Operatiqg  Env 
(CVOE) 

Contractor:  Raytheon  X\ 


Sensors 

FLIRS 


ProdbQt:  Bradley  OE  (VRTOS) 

Contracted  UDLP-San  Jose  Contractor:  TACOM 
_ _  Time:  1995-1996 


\  M2A3 


Product:  Vetronics  RT  Operating  Services 
(VRTOS) 


FSCS/T racer  CAT/RF  ATD 
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ProducfM>usader  OSS  /  RTQOE 

ContractoivUpLP-Minneapolisx^ 


MLRS 


Crusader 


Arinc  653 


Raytheon  (CVOE)  — 

United  Defense  (RTCOE,  OSS)  — 
Us  Army  TARDEC  (VRTOS)  — 

OAR  Corporation  (RTEMS) - 

SAE  (OS  API)  — 
POSIX  (RT,  Distributed,  SRASS)  — 

CORBA  — 


Raytheon  CVOE  Prototype 
OAR  RTEMS  Prototype 
TARDEC  Native/CORBA  Prototype 


POSIX 
RT  CORBA 

??? 
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UDLP  OSS  Prototype 
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OE  API  Components 


•  API  Specification 

►  Language  Independent  Specification  (LIS). 

►  Based  on  CORBA  Interface  Definition  Language  (IDL). 

•  Language  Bindings 

►  Ada  95  and  C  Language  bindings. 

•  Binary  Encodings 

►  Enables  object  access  among  distinct  OE  vendor  implementations. 

►  Based  on  CORBA  Common  Data  Representation  (CDR). 

►  Provides  opcode  definitions  and  rules  for  interchange. 

►  Provides  rules  for  object  registration  and  naming. 

►  Provides  protocol  mappings  (currently  TCP/IP  and  Implementation  Defined). 

•  Configuration 

►  File  structure  and  general  syntax. 

►  Partition  structure  and  syntax. 
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Adaptable  Graphics  Interface  Language  (AGIL) 
_ API _ 

•  Isolates  the  graphics  engine  hardware  and  software  dependencies 
from  the  application  software. 

►  Defines  an  interface  between  the  system  software  application  and  a  graphical 
engine. 

•  The  AGIL  logical  interface  is  defined  via  a  language  binding  to  a 
set  of  packages: 

►  AGIL  Primitives  -  Defines  primitive  data  types/objects  used  in  AGIL. 

►  AGIL  Device  -  Defines  the  core  AGIL  component,  encapsulating  application 
and  graphics  independence. 

►  AGIL  Event  -  Defines  the  primary  mechanism  utilized  for  interconnecting 
applications  with  the  graphical  device  subsystem. 

►  AGIL  Drawable  -  Defines  a  set  of  complex  graphical  objects  built  utilizing 
the  AGIL  device  API  for  development  of  an  application  SMI. 
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Weapon  Systems  Mapping  Services  API 


•  Defines  a  set  of  detailed  concepts,  functionality,  and  interfaces 
required  to  support  the  development  of  mapping  applications,  while 
addressing  underlying  architectural  support  issues  of  embedded  real 
time  systems  (e.g.  multitasking,  reentrancy,  and  blocking/non¬ 
blocking  execution). 

•  The  WSMS  Architecture  has  been  developed  to  provide: 

►  Application  scalability,  such  that  groups  of  functionality  and  differing  data 
standards  and  formats  can  be  supported  to  meet  varying  system  requirements. 

►  Application  extensibility ,  such  that  future  upgrades  can  be  easily  incorporated 
to  provide  for  advances  in  mapping  system  technologies. 

►  Support  for  the  development  of  weapon  system  mapping  implementations 
meeting  real  time  embedded  performance  and  integration  requirements. 

►  Support  for  the  development  of  mapping  implementations  and  applications 
within  varying  application  architectures  using  varied  graphics  subsystems , 
hardware ,  software,  and  programming  languages. 


5/31/2001 


12 


WSMS  API  Architecture  (Class  Diagram) 

•  Developed  as  a  set  of  abstract  and  concrete  classes  to  implement 
specific  functionality  in  the  areas  of: 

►  Raster  Maps 

►  Vector  Maps 

►  DTED  Maps 

►  Grids 

►  Overlays 

►  Self  Icons  I  Session  I 
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WSMS  API  Components 


•  API  Specification 

►  Language  Independent  Specification  (LIS). 

►  Described  using  a  modified  Backus  Naur  Form  (BNF)  notation. 

►  Abstracts  graphical  and  OS  dependencies: 

•  Graphics  concepts  are  abstracted  via  a  graphical  implementation  layer  (GIL). 

•  Underlying  graphical  engine  is  not  assumed  (e.g.  could  be  X,  OpenGL,  Win32, 
DirectX,  ...). 

•  Language  Bindings 

►  Ada  83,  Ada  95,  and  C++  Language  bindings. 
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Terrain  Services  API 


Provides  an  interface  to  perform  critical  terrain  analysis  functions 
independent  of  operating  environment  and  application  developer. 
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Terrain  Services  API  (Cont.) 


•  Path  Analysis 

►  Calculation  of  mobility  corridors. 

•  Determination  of  choke  points  or  restrictions  identification  along  a  path. 

•  Calculation  of  travel  times  along  a  path. 

•  Range  Analysis 

►  Computation  of  minimum  time,  route  and  location  to  intercept  a  moving 
object. 

►  Identification  of  possible  locations  at  some  future  time  for  moving  objects. 

•  Terrain  Categorization 

►  Categorization  of  terrain  with  client  selectable  parameters. 

►  Identification  of  areas  within  given  parameters. 

•  Line  of  Sight 

►  Computation  of  visible  line  of  sight  from  a  location  within  an  area. 

►  Computation  of  direct  fire  weapons  line  of  sight  area  from  a  location. 

►  Identification  of  optimal  observation  points  within  a  given  area. 
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Performance,  Analysis  &  Measurement  API 


•  Extensible  tagged  event/sequence  generation,  recording,  and 
monitoring  system  mapped  to  the  “intelligent  taxonomy”  to  measure 
defined  mission  scenarios/tasks  (end  to  end). 

•  Primary  Functions: 

►  Internal  -  Generation  Component. 

►  External  -  Collection,  Monitoring,  &  Analysis  Component. 


Vetronics  Station  (Generation) 


• 

• 
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Vetronics  Station  (Generation) 
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Collection,  Monitoring,  &  Analysis 
Supports: 

-  Distributed  RT  Integration 

-  Test 

-  Data  Recording 

-  Data  Analysis 
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Performance,  Analysis  &  Measurement  (Cont.) 


•  Generation  Component  (Internal) 

►  Application  interface  is  provided  as  an  OO  API  with  Ada  95  and  C++ 
bindings. 

►  Provides  the  ability  to  extend  the  base  message  to  include  additional 
architecture  and  application-defined  data  fields. 

►  Provides  the  ability  to  control  the  routing  and  destination  of  output  message 
data  (internally  for  recording  or  externally  for  monitor/analysis). 

•  Collection,  Monitoring,  &  Analysis  Component  (External) 

►  Capture/Monitoring  Functions: 

•  Provides  the  ability  to  capture  directed  message  data  from  the  system  in  real  time. 

•  Provides  the  ability  to  retrieve/view/filter  recorded  data/messages  from  the  target 
system  for  analysis. 

►  Analysis  Functions: 

•  Provides  the  ability  to  view  recorded  sequences  (threads)  as  an  end  to  end  set  of 
actions. 

•  Provides  the  ability  to  measure  timing  between  discrete  events. 
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Station  Management  API 


•  Provides  a  conceptual  “software  backplane”  to  facilitate  application 
integration  and  system  upgrade. 

•  Primary  Functions: 

►  Application  loading  and  startup  synchronization. 

►  Application  runtime  synchronization. 

►  Application  subfunction  health  monitoring. 


Vetronics  Station 
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Station  Management  API  (Cont.) 


•  Architecture 

►  A  station  manager  is  resident  on  each  computing  node  in  the  system,  with  one 
station  manager  being  designated  as  the  master  for  the  station. 

•  The  station  master  provides  for  the  synchronization  of  each  node  in  the  system. 

•  The  station  manager  provides  a  base  concept/set  of  operations  for  a  system  state 
and  mode  and  hardware  registry  which  can  be  extended  to  a  system  specific 
context  as  required  for  the  application. 

•  Application  loading  and  startup  synchronization: 

►  Provides  the  ability  to  interpret  a  static  configuration  file  in  order  to 
dynamically  load/start  subfunctions  among  the  computing  elements  within  the 
Vetronics  stations. 


•  Application  runtime  synchronization: 

►  Provides  the  ability  for  application  subfunctions  to  synchronize  at  defined 
synch  points. 

•  Application  subfunction  health  monitoring. 

►  Provides  the  ability  to  monitor  the  application  subfunction  health. 
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•  Provides  the  ability  to  report  health  anomalies  to  the  system  application. 
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